home *** CD-ROM | disk | FTP | other *** search
/ Aminet 30 / Aminet 30 (1999)(Schatztruhe)[!][Apr 1999].iso / Aminet / dev / debug / MemSniff.lha / MemSniff / BugReport next >
Text File  |  1997-05-25  |  3KB  |  67 lines
  1. Howdy!
  2.  
  3. I have to apologize for the broken 1.09 release of MemSniff - it caused 
  4. really a lot of crashes. After a long debug session for over eight hours 
  5. it turned out that this problem was not caused by MemSniff, but by 
  6. "MagicMenu" ! 
  7.  
  8.  
  9. So here's what was going on:
  10.  
  11. The workbench task displays the size and free storage of available volumes
  12. in the title bar of the workbench windows. To avoid memory defragmentation,
  13. the algorithm of updating this title bar works like this:
  14.  
  15. - Determinate the total size and the number of available blocks of
  16.   all devices.
  17.  
  18. - Create a new window title from the new information.
  19.  
  20. - Allocate new memory to hold the new title.
  21.  
  22. - Read the title bar pointer from the workbench window (this is important!)
  23.   and compare the current title bar string with the old one.
  24.   If nothing changed, free the new title (to avoid defragmentation) and
  25.   leave the title alone.
  26.  
  27. - If the title has changed: Read the title bar string pointer from the
  28.   workbench window (!) free it and set the new window title to the new
  29.   string.
  30.  
  31. This is the point of the operation where MagicMenu interacts, as the 
  32. SetWindowTitle() procedure is patched to a private MagicMenus procedure.
  33. It calls here TypeOfMem() to determinate the memory type of the new string
  34. to display as memory title. I've no idea why this is necessary or what this
  35. should be good for since resident titles in the ROM are totally legal. 
  36. Anyways, if the title is not in valid RAM, the SetWindowTitle() operation
  37. is aborted, no idea why.
  38.  
  39. Since MemSniff divides the total system memory in two parts, giving one to
  40. the system and checking the other, it might well happen that the pointer
  41. to the new window title is NOT in system memory, but in this part of the
  42. memory that is currently checked by MemSniff. As a result, TypeOfMem()
  43. returns zero, as it should do. As a result, MagicMenu aborts the 
  44. SetWindowTitle() call (no idea why) and leaves the old string pointer in
  45. the window structure. This old window title will, however, get FreeVec()'ed
  46. by the workbench on the next step, but since MagicMenu aborts the
  47. SetWindowTitles(), this invalid pointer is now still in the window structure.
  48.  
  49. On the next refresh, the workbench reads this invalid pointer, by assuming
  50. it is the last successfully installed window title - which is not true since
  51. MM canceled this operation - and tries to free it: ZAPPO!
  52.  
  53.  
  54. This bug was not at all obvious, and I would say aborting the 
  55. SetWindowTitles() operation by MagicMenu just like because the memory
  56. type was unkown is more than delicate. At LEAST, the new window title pointer
  57. should get installed in the window structure to make the workbench working
  58. in all cases. Remember, titles in the ROM are absolutely legal and I don't
  59. see a reason why MagicMenu aborts their installation. Anyways, I added a
  60. workaround for this behaiviour in the current release of MemSniff, so this
  61. problem is definitely fixed now.
  62.  
  63. I have really to apologize to all those people who tried to run MemSniff and
  64. where disappointed by its unstability. Sorry, sorry, sorry, guys!
  65.  
  66. Greetings,
  67.     Thomas